POM Introduction

Page Object Model (POM) is one of the most widely used design patterns in Selenium automation frameworks. It is used to organize Selenium code by separating web-page interaction logic from test-case logic.

In a traditional Selenium test, locators and browser interaction code are often written directly inside test methods. As the application grows, this can create duplicate code and make maintenance difficult. The Page Object Model solves this problem by representing each important application page as a separate Java class.

In POM, a page class generally contains the locators and methods required to interact with that page, while the test class focuses on test scenarios, test data, assertions, and execution flow.

Course Resource: Selenium Training | Register for Course Demo

1. What is Page Object Model?

Page Object Model, commonly called POM, is a design pattern used in Selenium automation where each application page or significant page component is represented by a separate class.

The page class contains the elements and actions associated with that page. Test classes use the methods provided by the page class instead of directly interacting with Selenium locators.

Test Class

    |
    v
Page Object Class
    |
    v
Locators + Page Actions
    |
    v
Selenium WebDriver
    |
    v
Web Application

2. Why is POM Important?

POM is important because Selenium automation projects can contain hundreds or thousands of test cases. If every test contains its own locators and interaction code, even a small UI change can require modifications in many files.

• Reduces duplicate Selenium code.
• Improves code maintainability.
• Provides better separation of responsibilities.
• Makes test cases easier to read.
• Improves code reusability.
• Centralizes page locators.
• Makes UI changes easier to manage.
• Supports scalable automation frameworks.
• Works well with TestNG and JUnit.
• Can be integrated with Data Providers and external test data.

3. POM Basic Concept

The main concept of POM is simple: create a separate class for each important application page and place that page's locators and interaction methods inside the class.

For example, an application may contain the following pages:

Application

 |
 +-- Login Page
 +-- Home Page
 +-- Product Page
 +-- Cart Page
 +-- Checkout Page
 +-- Profile Page

These pages can be represented by separate Java classes:

LoginPage.java

HomePage.java
ProductPage.java
CartPage.java
CheckoutPage.java
ProfilePage.java

4. Traditional Selenium Approach

Without POM, Selenium locators and actions are frequently written directly inside test methods.

import org.openqa.selenium.By;

import org.openqa.selenium.WebDriver;
 
public class LoginTest {
 
    WebDriver driver;
 
    public void loginTest() {
 
        driver.findElement(By.id("username"))
                .sendKeys("admin");
 
        driver.findElement(By.id("password"))
                .sendKeys("admin123");
 
        driver.findElement(By.id("loginButton"))
                .click();
    }
}

This approach may work for small scripts, but it becomes difficult to maintain when the same login functionality is used by many test cases.

5. Login Test Using POM

With POM, the login page is represented by a separate class.

import org.openqa.selenium.By;

import org.openqa.selenium.WebDriver;
 
public class LoginPage {
 
    WebDriver driver;
 
    By username = By.id("username");
    By password = By.id("password");
    By loginButton = By.id("loginButton");
 
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }
 
    public void enterUsername(String value) {
        driver.findElement(username).sendKeys(value);
    }
 
    public void enterPassword(String value) {
        driver.findElement(password).sendKeys(value);
    }
 
    public void clickLogin() {
        driver.findElement(loginButton).click();
    }
 
    public void login(String user, String pass) {
        enterUsername(user);
        enterPassword(pass);
        clickLogin();
    }
}

The test class can then use the page methods.

public class LoginTest {

 
    WebDriver driver;
    LoginPage loginPage;
 
    public void loginTest() {
 
        loginPage = new LoginPage(driver);
 
        loginPage.login("admin", "admin123");
    }
}

6. POM Architecture

A typical Selenium POM framework separates tests, page objects, utilities, test data, configuration, and reporting.

                    Selenium Framework

                           |
        +------------------+------------------+
        |                  |                  |
     Test Classes       Page Objects       Utilities
        |                  |                  |
        v                  v                  v
    Test Cases         Locators          Driver Factory
    Assertions         Actions           Config Reader
    TestNG             Methods           Wait Utility
        |                  |
        +--------+---------+
                 |
                 v
          Selenium WebDriver
                 |
                 v
          Web Application

7. Main Components of POM

• Page Classes: Represent application pages.
• Locators: Identify elements on the page.
• Page Methods: Perform actions on page elements.
• Test Classes: Execute business scenarios.
• WebDriver: Controls the browser.
• Test Data: Provides input values.
• Utilities: Provide reusable framework functionality.
• Configuration: Stores environment and framework settings.

8. Page Class

A page class represents a particular web page or a logical section of an application.

For example, a login page can be represented using LoginPage.java.

public class LoginPage {

 
    WebDriver driver;
 
    By username = By.id("username");
    By password = By.id("password");
    By loginButton = By.id("loginButton");
 
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }
}

9. Locators in POM

Locators identify web elements that Selenium needs to interact with.

Common Selenium locators include:

10. Page Methods

Page methods represent actions that a user can perform on a page.

public void enterUsername(String username) {

    driver.findElement(By.id("username"))
            .sendKeys(username);
}
 
public void enterPassword(String password) {
    driver.findElement(By.id("password"))
            .sendKeys(password);
}
 
public void clickLogin() {
    driver.findElement(By.id("loginButton"))
            .click();
}

These methods hide Selenium implementation details from the test class.

11. POM Constructor

The page object generally receives the WebDriver instance through its constructor.

public LoginPage(WebDriver driver) {

    this.driver = driver;
}

This allows the page object to use the same browser session created by the test or driver factory.

12. Why Pass WebDriver to Page Objects?

Page classes need access to WebDriver so they can locate and interact with elements.

WebDriver driver = new ChromeDriver();

 
LoginPage loginPage = new LoginPage(driver);
 
loginPage.login("admin", "admin123");

Here, the driver is created outside the page object and passed into the page object.

13. Encapsulation in POM

POM supports the object-oriented programming principle of encapsulation. Locators and page-specific implementation details can remain inside the page class while the test interacts with public methods.

Test

 |
 | loginPage.login()
 v
LoginPage
 |
 +-- username locator
 +-- password locator
 +-- login button locator
 |
 v
WebDriver

The test does not need to know how the login method finds or interacts with each element.

14. POM and Separation of Responsibilities

A good POM framework separates responsibilities.

15. POM with TestNG

POM is commonly combined with TestNG for structured Selenium automation.

import org.testng.annotations.Test;

 
public class LoginTest {
 
    WebDriver driver;
    LoginPage loginPage;
 
    @Test
    public void validLoginTest() {
 
        loginPage = new LoginPage(driver);
 
        loginPage.login("admin", "admin123");
    }
}

TestNG handles test execution while the page object handles page interactions.

16. POM with @BeforeMethod

Browser setup can be placed in a TestNG configuration method.

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
 
public class BaseTest {
 
    WebDriver driver;
 
    @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
        driver.manage().window().maximize();
    }
 
    @AfterMethod
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

17. POM with Base Test Class

A base test class can contain common setup and cleanup functionality.

public class BaseTest {

 
    protected WebDriver driver;
 
    @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
        driver.manage().window().maximize();
        driver.get("https://example.com");
    }
 
    @AfterMethod
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

Individual test classes can extend the base test class.

public class LoginTest extends BaseTest {

 
    @Test
    public void loginTest() {
 
        LoginPage loginPage = new LoginPage(driver);
 
        loginPage.login("admin", "admin123");
    }
}

18. POM with Page Navigation

A page method can return another page object when an action navigates to a different page.

public class LoginPage {

 
    WebDriver driver;
 
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }
 
    public HomePage login(String username, String password) {
 
        driver.findElement(By.id("username"))
                .sendKeys(username);
 
        driver.findElement(By.id("password"))
                .sendKeys(password);
 
        driver.findElement(By.id("loginButton"))
                .click();
 
        return new HomePage(driver);
    }
}

This approach can make page-to-page navigation easier to understand.

19. POM with Home Page

public class HomePage {

 
    WebDriver driver;
 
    By profile = By.id("profile");
    By logout = By.id("logout");
 
    public HomePage(WebDriver driver) {
        this.driver = driver;
    }
 
    public void openProfile() {
        driver.findElement(profile).click();
    }
 
    public void logout() {
        driver.findElement(logout).click();
    }
}

20. POM Page Flow

LoginTest

    |
    v
LoginPage
    |
    | login()
    v
HomePage
    |
    | openProfile()
    v
ProfilePage
    |
    | logout()
    v
LoginPage

This structure models the application's navigation flow using page objects.

21. POM with Search Page

public class SearchPage {

 
    WebDriver driver;
 
    By searchBox = By.id("search");
    By searchButton = By.id("searchButton");
 
    public SearchPage(WebDriver driver) {
        this.driver = driver;
    }
 
    public void search(String keyword) {
        driver.findElement(searchBox)
                .clear();
 
        driver.findElement(searchBox)
                .sendKeys(keyword);
 
        driver.findElement(searchButton)
                .click();
    }
}

The test can simply call:

SearchPage searchPage = new SearchPage(driver);

 
searchPage.search("Laptop");

22. POM with Data Provider

POM can be combined with TestNG Data Providers to execute the same page workflow using multiple data sets.

@DataProvider(name = "loginData")

public Object[][] loginData() {
    return new Object[][] {
        {"admin", "admin123"},
        {"manager", "manager123"},
        {"employee", "employee123"}
    };
}
 
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
 
    LoginPage loginPage = new LoginPage(driver);
 
    loginPage.login(username, password);
}

23. POM with Assertions

Assertions are generally placed in test classes because the test class is responsible for verifying expected behavior.

@Test

public void verifyLogin() {
 
    LoginPage loginPage = new LoginPage(driver);
 
    HomePage homePage =
            loginPage.login("admin", "admin123");
 
    Assert.assertTrue(
            driver.getTitle().contains("Dashboard")
    );
}

Page classes should primarily handle page interaction rather than becoming overloaded with test verification logic.

24. POM with Explicit Waits

Dynamic applications often require synchronization. Explicit waits can be encapsulated inside page methods or reusable wait utilities.

WebDriverWait wait =

        new WebDriverWait(driver, Duration.ofSeconds(10));
 
WebElement username =
        wait.until(
            ExpectedConditions.visibilityOfElementLocated(
                By.id("username")
            )
        );
 
username.sendKeys("admin");

25. POM and Reusable Wait Utility

A reusable wait utility can reduce duplicate synchronization code.

public class WaitUtils {

 
    private WebDriver driver;
    private WebDriverWait wait;
 
    public WaitUtils(WebDriver driver) {
        this.driver = driver;
        this.wait =
            new WebDriverWait(driver, Duration.ofSeconds(10));
    }
 
    public WebElement waitForElement(By locator) {
        return wait.until(
            ExpectedConditions.visibilityOfElementLocated(locator)
        );
    }
}

26. Page Object Model vs Normal Selenium Script

27. POM and Object-Oriented Programming

POM is closely related to object-oriented programming concepts.

• Class: Each page can be represented as a class.
• Object: Test classes create page objects.
• Encapsulation: Page details are encapsulated inside page classes.
• Abstraction: Complex Selenium actions can be exposed as simple methods.
• Inheritance: Common page behavior can be shared through base classes when appropriate.

28. POM and Abstraction

Abstraction allows the test to interact with a high-level business action instead of individual Selenium commands.

Instead of writing:

driver.findElement(By.id("username"))

        .sendKeys("admin");
 
driver.findElement(By.id("password"))
        .sendKeys("admin123");
 
driver.findElement(By.id("loginButton"))
        .click();

The test can use:

loginPage.login("admin", "admin123");

The page object hides the implementation details.

29. POM and Reusability

A page method can be reused by many tests.

loginPage.login("admin", "admin123");

The same method could be used by:

• Valid login test.
• Role-based login test.
• Regression test.
• Smoke test.
• Permission test.
• Session management test.

30. POM for Multiple Pages

A complete application may have many page objects.

pages

 |
 +-- LoginPage.java
 +-- HomePage.java
 +-- ProductPage.java
 +-- SearchPage.java
 +-- CartPage.java
 +-- CheckoutPage.java
 +-- PaymentPage.java
 +-- ProfilePage.java

Each page class should generally contain functionality relevant to that page or component.

31. POM for E-Commerce Application

For an e-commerce application, a POM framework might contain:

32. POM for Login Workflow

Login Test

    |
    v
Open Login Page
    |
    v
Enter Username
    |
    v
Enter Password
    |
    v
Click Login
    |
    v
Home Page
    |
    v
Verify Dashboard

33. Complete Login POM Example

The following example demonstrates a simple Selenium POM implementation.

import org.openqa.selenium.By;

import org.openqa.selenium.WebDriver;
 
public class LoginPage {
 
    private WebDriver driver;
 
    private By username =
            By.id("username");
 
    private By password =
            By.id("password");
 
    private By loginButton =
            By.id("loginButton");
 
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }
 
    public void enterUsername(String value) {
        driver.findElement(username)
                .sendKeys(value);
    }
 
    public void enterPassword(String value) {
        driver.findElement(password)
                .sendKeys(value);
    }
 
    public void clickLogin() {
        driver.findElement(loginButton)
                .click();
    }
 
    public void login(String username, String password) {
        enterUsername(username);
        enterPassword(password);
        clickLogin();
    }
}

34. Complete Test Class Using POM

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
 
public class LoginTest {
 
    private WebDriver driver;
 
    @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
        driver.manage().window().maximize();
        driver.get("https://example.com/login");
    }
 
    @Test
    public void validLoginTest() {
 
        LoginPage loginPage =
                new LoginPage(driver);
 
        loginPage.login("admin", "admin123");
 
        Assert.assertTrue(
                driver.getTitle().contains("Dashboard")
        );
    }
 
    @AfterMethod
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

35. POM with PageFactory

PageFactory is another Selenium-related approach historically used to initialize page elements in Page Object classes.

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;
import org.openqa.selenium.support.PageFactory;
 
public class LoginPage {
 
    WebDriver driver;
 
    @FindBy(id = "username")
    WebElement username;
 
    @FindBy(id = "password")
    WebElement password;
 
    @FindBy(id = "loginButton")
    WebElement loginButton;
 
    public LoginPage(WebDriver driver) {
        this.driver = driver;
        PageFactory.initElements(driver, this);
    }
 
    public void login(String user, String pass) {
        username.sendKeys(user);
        password.sendKeys(pass);
        loginButton.click();
    }
}

36. POM with @FindBy

The @FindBy annotation can be used to define page elements.

@FindBy(id = "username")

WebElement username;
 
@FindBy(name = "password")
WebElement password;
 
@FindBy(css = "button[type='submit']")
WebElement loginButton;

This approach can make page classes concise, although teams should choose a consistent element strategy for their framework.

37. PageFactory vs By Locators

38. POM Locator Visibility

Page locators should generally be hidden from test classes. Keeping locators private improves encapsulation.

private By username =

        By.id("username");
 
private By password =
        By.id("password");

The test should interact through methods such as:

loginPage.login("admin", "admin123");

39. POM Method Naming

Page methods should use meaningful names that describe user actions or business operations.

Good examples:

login()

searchProduct()
addProductToCart()
removeProduct()
proceedToCheckout()
enterShippingAddress()
logout()

Meaningful method names make test cases easier to understand.

40. Business-Level Page Methods

A good POM can expose business-level actions instead of exposing every low-level Selenium command.

For example, instead of:

clickUsername();

enterUsername();
clickPassword();
enterPassword();
clickLoginButton();

A business-level method can provide:

loginPage.login("admin", "admin123");

This makes the test closer to the actual business scenario.

41. POM and Component Objects

Not every reusable UI section needs to be a complete page. Reusable components such as headers, menus, product cards, calendars, and navigation bars can also be represented by classes.

components

 |
 +-- HeaderComponent.java
 +-- MenuComponent.java
 +-- ProductCard.java
 +-- CalendarComponent.java

42. Page Object vs Component Object

43. POM Framework Structure

src

 |
 +-- main
 |   +-- java
 |       +-- pages
 |       |   +-- LoginPage.java
 |       |   +-- HomePage.java
 |       |   +-- ProductPage.java
 |       |
 |       +-- utilities
 |           +-- DriverFactory.java
 |           +-- WaitUtils.java
 |           +-- ConfigReader.java
 |
 +-- test
     +-- java
         +-- tests
             +-- LoginTest.java
             +-- ProductTest.java
             +-- CheckoutTest.java

44. POM with Driver Factory

A Driver Factory can centralize browser creation.

public class DriverFactory {

 
    public static WebDriver createDriver(String browser) {
 
        if (browser.equalsIgnoreCase("chrome")) {
            return new ChromeDriver();
        }
 
        if (browser.equalsIgnoreCase("firefox")) {
            return new FirefoxDriver();
        }
 
        throw new IllegalArgumentException(
                "Unsupported browser: " + browser
        );
    }
}

The test can obtain a driver from the factory and pass it to page objects.

45. POM with Configuration

Application URLs and environment-specific values can be stored in configuration files rather than hard-coded throughout the framework.

baseUrl=https://example.com

browser=chrome
timeout=10

A configuration reader can load these values and the test framework can use them during execution.

46. POM with Multiple Environments

POM itself does not manage environments, but it can work with a configuration layer to support QA, staging, and other environments.

QA

 |
 +-- https://qa.example.com
 
STAGE
 |
 +-- https://stage.example.com
 
PRODUCTION
 |
 +-- https://www.example.com

47. POM with Test Data

Test data should generally remain separate from page interaction logic.

Test Data

    |
    v
Test Method
    |
    v
Page Object
    |
    v
WebDriver
    |
    v
Application

This separation makes the framework easier to maintain.

48. POM with Data Providers and Test Data

@DataProvider(name = "users")

public Object[][] users() {
    return new Object[][] {
        {"admin", "admin123"},
        {"manager", "manager123"}
    };
}
 
@Test(dataProvider = "users")
public void loginTest(String username, String password) {
 
    LoginPage loginPage =
            new LoginPage(driver);
 
    loginPage.login(username, password);
}

49. POM and Selenium WebDriver

Selenium WebDriver remains responsible for browser automation. POM is an organizational design pattern that provides a structured way to use WebDriver.

POM

 |
 v
Page Methods
 |
 v
WebDriver
 |
 v
Browser
 |
 v
Web Application

50. POM and Test Reports

POM can be integrated with reporting tools. The page object performs actions while the test or reporting layer records test steps, results, and failures.

Test

 |
 +-- Report: Start Test
 |
 +-- Page Object Action
 |
 +-- Selenium Action
 |
 +-- Assertion
 |
 +-- Report: Pass / Fail

51. POM and CI/CD

A POM-based Selenium framework can be executed through CI/CD systems.

Developer Commit

      |
      v
CI/CD Pipeline
      |
      v
Build
      |
      v
Test Execution
      |
      v
POM Framework
      |
      v
Selenium WebDriver
      |
      v
Browser
      |
      v
Test Results
      |
      v
Reports

52. POM and Parallel Execution

POM can support parallel test execution, but page objects and WebDriver instances must be designed correctly for concurrent execution.

A common architecture is:

Thread 1

 |
 +-- WebDriver 1
 +-- LoginPage 1
 +-- Test 1
 
Thread 2
 |
 +-- WebDriver 2
 +-- LoginPage 2
 +-- Test 2

Sharing one mutable WebDriver instance across concurrent tests can cause test interference.

53. Advantages of POM

• Maintainability: UI changes can often be handled within page classes.
• Reusability: Page methods can be used by multiple tests.
• Readability: Tests become easier to understand.
• Encapsulation: Locators and implementation details remain inside page classes.
• Scalability: The structure can support large automation projects.
• Reduced Duplication: Common page interactions are implemented once.
• Separation of Concerns: Test logic and UI interaction are separated.
• Easy Maintenance: Centralized locators simplify maintenance.
• Framework Integration: POM works with TestNG, Maven, CI/CD, Data Providers, and reporting tools.

54. Limitations of POM

• Large applications can result in many page classes.
• Poorly designed page objects can become very large.
• Changing application workflows may require updates to several page methods.
• Over-abstraction can make simple tests unnecessarily complicated.
• Developers need a consistent framework structure.
• Dynamic applications may require additional synchronization and component strategies.

55. Common Mistakes in POM

• Putting all application functionality into one page class.
• Making every locator public unnecessarily.
• Putting assertions everywhere inside page classes.
• Duplicating the same page methods across classes.
• Hard-coding environment-specific values in page classes.
• Sharing WebDriver incorrectly between parallel tests.
• Creating methods that only wrap one trivial Selenium command without adding useful abstraction.
• Mixing test data management with page interaction logic.
• Ignoring synchronization issues.
• Using unclear page and method names.

56. Best Practices for POM

• Keep page classes focused on a page or reusable component.
• Keep locators encapsulated.
• Use meaningful method names.
• Create business-level methods where appropriate.
• Keep test assertions primarily in test classes.
• Use reusable utility classes for common framework functions.
• Keep test data separate from page objects.
• Use explicit waits for dynamic elements when required.
• Avoid unnecessary inheritance.
• Use a consistent naming convention.
• Design WebDriver management for the required execution model.
• Keep configuration separate from page interaction logic.
• Review page classes regularly to prevent them from becoming too large.

57. POM Naming Conventions

58. Practical Project Structure

selenium-pom-framework

 |
 +-- pom.xml
 |
 +-- src
     |
     +-- main
     |   +-- java
     |       +-- pages
     |       |   +-- LoginPage.java
     |       |   +-- HomePage.java
     |       |   +-- SearchPage.java
     |       |   +-- ProductPage.java
     |       |   +-- CartPage.java
     |       |
     |       +-- utilities
     |           +-- DriverFactory.java
     |           +-- WaitUtils.java
     |           +-- ConfigReader.java
     |
     +-- test
         +-- java
             +-- tests
                 +-- LoginTest.java
                 +-- SearchTest.java
                 +-- ProductTest.java
                 +-- CheckoutTest.java

59. Complete POM Workflow

TestNG Test

    |
    v
Create / Obtain WebDriver
    |
    v
Create Page Object
    |
    v
Call Page Method
    |
    v
Page Object Finds Element
    |
    v
WebDriver Performs Action
    |
    v
Application Responds
    |
    v
Test Performs Assertion
    |
    v
Test Result / Report

60. Real-World Login Project

Consider an application with a login page containing username, password, and login button.

The framework can be organized as:

LoginTest

    |
    v
LoginPage
    |
    +-- username
    +-- password
    +-- loginButton
    |
    v
login()
    |
    v
Dashboard
    |
    v
DashboardPage

This structure allows login functionality to be reused by multiple tests without duplicating Selenium locators.

61. POM vs Data-Driven Testing

POM and data-driven testing solve different problems and can be used together.

62. POM vs Hard-Coded Selenium Scripts

63. Interview Questions on POM

1. What is POM?

POM stands for Page Object Model. It is a design pattern used to organize Selenium automation by representing application pages as classes.

2. Why is POM used in Selenium?

POM is used to improve maintainability, readability, reusability, and separation of test logic from page interaction logic.

3. What does a page object contain?

A page object commonly contains page locators and methods that perform actions on the corresponding page.

4. Should assertions be placed inside page objects?

Assertions are generally better placed in test classes so that page objects primarily handle page interaction. Some framework designs may expose state or verification methods from page objects.

5. Why is WebDriver passed to a page object?

The page object needs access to WebDriver to locate and interact with web elements.

6. Can POM be used with TestNG?

Yes. POM is commonly combined with TestNG for Selenium automation.

7. Can POM be used with Data Providers?

Yes. Data Providers can supply test data while POM handles page interactions.

8. What is PageFactory?

PageFactory is a Selenium support mechanism historically used to initialize page elements declared with annotations such as @FindBy.

9. What is the difference between POM and PageFactory?

POM is a design pattern for organizing page objects. PageFactory is an element-initialization approach that can be used within page objects.

10. Can a page object contain another page object?

Yes. Page objects can compose reusable components or represent navigation to other pages.

11. What is encapsulation in POM?

Encapsulation means keeping page implementation details such as locators inside the page class and exposing controlled methods to the test.

12. What is the main advantage of POM?

One major advantage is that UI interaction logic can be reused and maintained independently from individual test cases.

13. Can POM support parallel execution?

Yes, provided that WebDriver and page-object instances are managed safely for each concurrent test execution.

14. What is a BaseTest class?

A BaseTest class commonly contains shared test setup and cleanup functionality such as WebDriver initialization and browser termination.

15. What is a component object?

A component object represents a reusable section of a web page, such as a header, menu, product card, or calendar.

16. Why should locators be private?

Private locators improve encapsulation and prevent test classes from directly depending on page implementation details.

17. Can POM be used with Maven?

Yes. Maven can manage dependencies and execute POM-based Selenium test projects.

18. Can POM be integrated with CI/CD?

Yes. POM-based Selenium frameworks can be executed in CI/CD pipelines.

19. What is business-level abstraction in POM?

Business-level abstraction means exposing actions such as login, searchProduct, and checkout instead of requiring tests to perform individual low-level Selenium commands.

20. Why is POM useful for large projects?

POM provides a structured approach for organizing page interactions, reducing duplication, and maintaining automation code as the application grows.

64. Quick Reference Table

65. Learning Roadmap for POM

1. Learn Selenium WebDriver basics.
2. Understand Java classes and objects.
3. Learn Selenium locators.
4. Understand methods and constructors.
5. Understand the Page Object Model concept.
6. Create a simple LoginPage class.
7. Pass WebDriver to page objects.
8. Create reusable page methods.
9. Separate test classes from page classes.
10. Create a BaseTest class.
11. Implement reusable utilities.
12. Combine POM with TestNG.
13. Combine POM with Data Providers.
14. Add explicit waits and synchronization.
15. Implement Driver Factory.
16. Add configuration management.
17. Integrate reporting.
18. Integrate Maven.
19. Execute the framework through CI/CD.
20. Build a complete real-world POM framework.

66. Practical Exercises

1. Create a LoginPage class with username, password, and login button locators.
2. Create a HomePage class with navigation methods.
3. Create a SearchPage class with a reusable search method.
4. Create a ProductPage class for product selection.
5. Create a CartPage class for cart operations.
6. Create a CheckoutPage class for checkout functionality.
7. Create a BaseTest class for WebDriver setup and cleanup.
8. Create a Data Provider for multiple login users.
9. Use the Data Provider with LoginPage.
10. Create a reusable WaitUtils class.
11. Create a DriverFactory for Chrome and Firefox.
12. Build a complete e-commerce POM framework.

67. Real-World POM Architecture

                    Test Cases

                        |
                        v
                  TestNG / JUnit
                        |
                        v
                  Page Objects
                        |
          +-------------+-------------+
          |             |             |
       LoginPage    SearchPage    CartPage
          |             |             |
          +-------------+-------------+
                        |
                        v
                  Utility Layer
                        |
          +-------------+-------------+
          |             |             |
      DriverFactory  WaitUtils   ConfigReader
          |
          v
      Selenium WebDriver
          |
          v
        Browser
          |
          v
     Web Application
          |
          v
       Assertions
          |
          v
        Reports

68. POM Best-Practice Flow

Test Data

    |
    v
Test Class
    |
    v
Page Object
    |
    v
Reusable Page Method
    |
    v
Locator
    |
    v
WebDriver
    |
    v
Browser
    |
    v
Application
    |
    v
Verification
    |
    v
Test Report

69. Summary

Page Object Model (POM) is a design pattern that provides a structured approach to Selenium automation. It represents application pages or reusable UI components as classes and keeps their locators and interaction methods organized within those classes.

POM helps separate test logic from Selenium interaction logic. Instead of placing locators and browser commands directly inside every test, tests can call reusable page methods such as login(), searchProduct(), addProductToCart(), and checkout().

POM becomes especially useful in large Selenium projects where multiple tests interact with the same application pages. If a locator changes, the corresponding page object can often be updated without modifying every test that uses the page functionality.

POM can be combined with TestNG, Data Providers, WebDriver factories, configuration management, explicit waits, reporting tools, Maven, CI/CD pipelines, and parallel execution strategies to create a maintainable Selenium automation framework.

Final Takeaway: POM separates what the test wants to verify from how the application page is interacted with. This separation improves organization, reuse, readability, and maintainability of Selenium automation code.

70. Course Resources

Learn more about Selenium WebDriver, automation frameworks, Page Object Model, TestNG, and related testing concepts:

• Selenium Training
• Register for Selenium Course Demo